Hi, this patch responds to the issue raised in #885 (rf bridge and energenie remotes) being able to receive but not to transmit codes from the rf bridge.

In the initial implementation I suppressed the timing information from rc-switch output in order to emit consistent RC codes (if timing varies from one key stroke to the other, the consumer the other side of MQTT would have a hard time to recognize the varying code.

The varying time in RC codes is an issue also in the 'vanilla' rf-bridge implementation, as signaled also in #910 (Controlling rf433 bridge via MQTT broker)

The changes I have made for the -direct firmware address these points.

• Embed timing information in received codes from received RF
• Use embedded timing information, if available, transmitting to RF
  (if timing is not available, the default timing for protocol is used from rc-switch)
• Prevent watchdog from kicking in during codes TX
• Mitigate timing variability replacing, when available, the current rf code with the learned one.

In practice, when we receive an RF code we first try to match with learned ones. If that matches, the stored one replaces the received one (standardizes it) before continuing the processing and publishing to MQTT, or whatever. This also allows to store a 'known' code by hand with the UI interface and keep a consistent output everywhere, avoiding the timing variance brought while learning.

I made this latest change independent from bridge hacks (vanilla, direct, and portish) variants as I think they can all benefit the improvement. In particular, it might ease the issue #910 too.

This patch relies on the standard rc-switch library and in consequence of this does not contain the rf tracing features.